Field of the Disclosure
Various features relate to wireless communication networks and to security procedures for use in authenticating mobile devices or other User Equipment (UE) to networks equipped for use in accordance Long-Term Evolution (LTE) standards.
Description of Related Art
Wireless communication networks such LTE networks employ various types of security schemes. By way of example, the WiFi Alliance HotSpot 2.0 (Release 2) Technical Specification v1.1.0 provides various security features. HotSpot 2.0 (herein-after HS2.0) includes an online sign up (OSU) process by which a mobile device registers with a Service Provider (SP), enabling a user to select a plan for obtaining network access, and is then provisioned with the credentials necessary to securely connect to an Access Network (AN). The OSU process is facilitated by the SP's OSU Server. The resulting credentials are provided to the Authentication, Authorization and Accounting server (AAA) of the SP. The OSU process begins by establishing a Transport Layer Security (TLS) connection between the mobile device and the OSU Server. The remaining provisioning steps can depend on the mobile device credentials that the AAA uses to authenticate the mobile device. HS2.0 supports three main options for mobile device credentials. Table I, below, summarizes these options, as well as summarizing the OSU procedures for use with these particular credentials. Note that some of these methods exploit one or more of Extensible Authentication Protocol (EAP), with the EAP-TLS (Transport Layer Security) EAP Method and/or EAP-TTLS (Tunneled TLS) method. Other acronyms used include HLOS for High Level Operating System, CA for Certificate Authority and EST for Enrollment Over Secure Transport. MSCHAPv2 refers to a particular Challenge-Handshake Authentication Protocol (CHAP) provided by Microsoft™. RFC 7030 refers to Request for Comment (RFC) 7030 of the Internet Engineering Task Force (IETF) of October 2013.
TABLE IAuthenticationMobileof MobileEAP methodDevicedevice andused byCredentialsOSU ServerOSU Server actionsAAAMETHOD 1:Username &TLS with OSUOSU Server selectsEAP-TTLS:passwordServerand configuresTLS with AAAcertificateusername &certificate, andpasswordMSCHAPv2 withusername &passwordMETHOD 2:SP-issuedTLS with OSUFacilitates a CA toEAP-TLS: TLScertificateServerissue a SP-issueduses AAAwhose privatecertificatecertificate. ESTcertificate & SP-key is(RFC 7030) mayissued certificateavailable onlybe used.to mobiledevice HLOS.METHOD 3:Pre-configuredTLS with OSUForwards mobileEAP-TLS: TLSmobile deviceServerdevice certificateuses AAAcertificatecertificate &to AAAcertificate &mobile devicemobile devicecertificateCertificate
The mobile device's interaction with the OSU Server occurs only as required to establish the mobile device credentials in the first column of Table I. These mobile device credentials typically have a long lifetime. Once the mobile device credentials are established, the mobile device credentials are then used by the AAA to authenticate the mobile device when it requests access from the Service Provider. The frequency of the authentication with the AAA depends on a variety of factors, but typically occurs many times within the lifetime of the mobile device credential.
The implementation of credential storage and credential processing is outside the scope of HS2.0. In the cases of username/password credentials and SP-issued certificates, there is no authentication of the mobile device to the OSU Server in HS2.0, and consequently the OSU Server can make no assumptions about the implementation of the credential storage and credential processing. In the case of a pre-configured mobile device certificate, the OSU Server might be able to make some assumptions about implementation of the credential storage and credential processing if the mobile device certificate issuance process included some assurance about the implementation. However, in general it is assumed in HS2.0 that the credentials are stored and processed by the mobile device HLOS. The storage and processing provided by the HLOS may be vulnerable to attacks. The complexity of most or all HLOS means that, despite efforts to secure the HLOS, the HLOS will likely always be vulnerable to some attacks.
There is a need in the art to provide improved security for systems similar to HS2.0. In particular, it would be desirable to provide options for provisioning credentials and authentication with the OSU and AAA that are analogous to the options for HS2.0 while also providing security assurances associated with a more secured environment. Herein, an exemplary system or procedure directed to these ends is referred to as Retail-based Neutral Host LTE authentication.